In typical database systems, users store, update and retrieve information by submitting commands to a database application. To be correctly processed, the commands must comply with the database language that is supported by the database application. One popular database language is known as Structured Query Language (SQL).
A logical unit of work that is comprised of one or more database language statements is referred to as a transaction. In a database server, a memory area called the System Global Area (SGA) is allocated and one or more processes are started to execute one or more transactions. The combination of the SGA and the processes executing transactions is called a database instance.
Some database systems provide a buffer cache that is shared among the processes that are executing transactions in a database. The buffer cache resides in a portion of the SGA and holds database information. Buffers in the buffer cache hold copies of data blocks that have been read from the data files of the database. The buffers are shared by the user processes concurrently connected to the instance. When a transaction desires to make a change to a data block, a copy of the data block is loaded into a buffer of the buffer cache and the change is made to the copy of the data block stored in the database buffer cache in dynamic memory. At some time subsequent to when a transaction makes a change data in the buffer cache, one of the database processes, referred to herein as the "database writer", writes the modified blocks of data from the database buffer cache to the data files on disk.
Several problems can halt the operation of a database or affect the writing of database information to disk. Common types of failures include:
statement failures, involving a logical failure in the handling of a statement in the database program, such logical failures include, for example: SQL statement errors, internal database errors, or resource problem errors; PA1 process failures, involving a failure in a user, server, or background process of a database instance; PA1 network failures, involving an interruption in the normal operation of the communication network connecting the database computers; and PA1 media failures, involving a physical problem reading or writing physical files needed for normal database operation.
Another type of failure is an instance failure. An instance failure can occur when a problem arises that prevents an instance from continuing work. Instance failures may result from hardware problems such as a power outage, or software problems such as an operating system crash. Instance failures can also occur expectedly, for example, when a SHUTDOWN ABORT or a STARTUP FORCE statement is issued.
A major aspect of database operation and administration involves the recovery of the database from the various types of failures encountered. Recovery processes vary depending on the type of failure that has occurred, the structures that have been affected, and the type of recovery that is desired.
Several structures and procedures may be implemented to safeguard a database against possible failures. One procedure is to perform an operating system backup of the program and data files that constitute the database. Another is to mirror the database to a separate storage device so that two identical copies of the database are always maintained. A third method is to record all changes made to a database by maintaining a log of every database instance.
The database backup and mirroring techniques typically require a significant amount of memory, generally requiring at least as much memory as occupied by the entire database itself since they involve duplicating the database to another storage medium. These duplicative methods also require increased user input since periodic operations must be performed, such as running the backup program.
An alternate approach to duplicating the entire database involves maintaining logs of operations. According to the logging approach, several different operation logs are maintained to perform various database maintenance functions. Specifically, a redo log is used to store database operations so that the operations can be re-performed to restore the database to its pre-failure state after a failure. For example, when a transaction modifies data in the data cache, a redo entry that specifies the modification is stored in a redo log on disk. If a failure occurs before the updated data within the buffer cache has been stored to disk, the modified data in the buffer cache may be lost. Under these conditions, the database may be modified based on the redo entry during the recovery process.
After a crash, the database should be returned to a state in which the database reflects either all of none of the changes made by any given transaction. If a transaction had not committed when the crash occurred, then any changes made by the transaction up to that point must be removed from the database. Therefore, in addition to a redo log, an undo log may be maintained to allow changes to be selectively removed from the database during a recovery operation. Specifically, when a transaction makes a change to the database, an undo entry is generated that indicates how to remove the change from the database. If the transaction is unable to complete successfully, the undo entries generated for the transaction may be applied to remove all changes made to the database by the transaction.
The basic component of a log system is a log file stored on disk. Redo log files are filled with redo entries that store low-level representations of database changes. Redo entries contain the information necessary to reconstruct, or redo, changes made by data operations such as INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. Redo entries are generated for each change made to a copy of a data block stored in the database buffer cache. In one implementation, a redo log buffer is a circular buffer that holds information about update operations recently performed by transactions. The redo log buffer is written to an active online redo log file group on disk by a background process. The records in the online redo log file group on disk are referred to as redo logs.
It should be noted that one log could be used to store transaction information for both redo and undo operations, or a separate log could be maintained for each function. If a separate log is maintained to store undo information, the procedure for creating the undo log and undo log buffer is essentially identical to the procedure for creating the redo log and redo log buffer as described above.
System resources are required to generate log entries, maintain a log buffer in dynamic memory, and maintain a log file on disk. The redo entries take up continuous, sequential space in the log buffer. The log buffer can occupy a significant amount of random access memory, while the log file can occupy a significant amount of disk space. Moreover, the need to generate log entries when any update operation is performed slows down the execution of the update operation. If separate logs are maintained for redo and undo operations, the memory requirements and cycle time are correspondingly increased. Thus, logging causes database operations to execute more slowly and take up more memory. If the database system includes transactions or operations that do not need to be re-performed in case of failure, then logging every operation may result in a significant waste of time and computer resources.
Based on the foregoing, it is desirable to provide a database system in which logging, with its associated overhead, may be avoided in those situations that do not require the redo and undo functionality that logging provides.